home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000170_icon-group-sender _Fri Jul 30 07:26:11 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  3KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA04723
  4.     for icon-group-addresses; Fri, 30 Jul 1999 07:25:27 -0700 (MST)
  5. Message-Id: <199907301425.HAA04723@baskerville.CS.Arizona.EDU>
  6. From: gep2@terabites.com
  7. Date: Thu, 29 Jul 1999 18:48:11 -0500
  8. Subject: How to Bring Back the Old basename
  9. To: icon-group@optima.CS.Arizona.EDU
  10. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  11. Status: RO
  12.  
  13. > Nevin Liber has a good point regarding basename. Even if the latest version
  14. is closer to the original intentions, as well as the closer to what the name
  15. suggests, there may be many applications dependant on the old behavior. 
  16.  
  17. I'm going to make several observations here.
  18.  
  19. > To keep these applications from breaking, we need to retain the old, quirky
  20. behavior. This is unfortunate for new developers who would rather have
  21. something closer to the Unix utility.
  22.  
  23. Personally, I have no vested interest (or other interest, for that matter) in 
  24. making ANYTHING work like some Unix version does... I consider Unix in general 
  25. to be an anachronistic relic, with crappy documentation standards and inherently 
  26. anarchistic ongoing development efforts.  And I also don't consider it 
  27. particularly compelling to argue that any given name (especially something as 
  28. generic as "basename") has any kind of copyright on the name, giving them the 
  29. right to define what said named function does (or doesn't do) forever and ever 
  30. amen.
  31.  
  32. And that's especially true when the function's behavior can be argued to be 
  33. "broken" in the way an old, stupid, anachronistic implementation did things.
  34.  
  35. > Has anyone else noticed how superfluous the second parameter to the old
  36. basename is? The old basename chops off the extension whether or not the
  37. second parameter is specified, and whether or not it is present, so when
  38. does specifying an extension make a difference?
  39.  
  40. > The best option for now may be to fix basename to return the old behavior,
  41. and also update the documentation to clarify the quirk. Here is my proposal:
  42.  
  43. I think my recommendation would be to specify in the documentation and/or 
  44. routine comments that this routine has a number of quirks and odd behavior, and 
  45. give some specific examples showing cases that might yield unexpected results.  
  46. It would be perfectly reasonable to compare (in the comments) how the 
  47. old-fashioned Unix-y "basename", the "old Icon" basename, and the "new Icon" 
  48. basename would behave in the same situations.     
  49.  
  50. Yet another approach might be to add a third "mode" parameter, which could be 
  51. set to different values specifying which type of behavior one wanted from the 
  52. routine.  
  53.  
  54. To eliminate unwanted "default" behavior, one might purposely "break" old 
  55. programs by requiring that the third mode parameter be explicitly provided... 
  56. this would attract attention to the comments in the revised routine and force 
  57. the programmer to decide (and specify) which behavior he (or she) wants.
  58.  
  59.  
  60.  
  61. Gordon Peterson
  62. http://web2.airmail.net/gep2/
  63. Support the Anti-SPAM Amendment!  Join at http://www.cauce.org/
  64. 12/19/98: the day the Conservatives demonstrated their scorn for their
  65.    fraudulent sham of representative government.  Voters, remember it!
  66.  
  67.